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1.0  INTRODUCTION 

This  chapter  explains  the  purpose  of  the  convention,  the  scope  of 
the  guidance,  and  provides  an  explanation  of  how  to  use  the 
convention. 

1.1  PURPOSE  OF  THE  CONVENTION 

The  convention  provides  general  guidance  on  the  implemf^ntation 
of  American  National  Standards  Institute  (ANSI)  Accredited  Stand¬ 
ards  Committee  (ASC)  XI2  electronic  data  interchange  (EDI) 
standards  within  automated  information  systems  (AIS)  and  infor¬ 
mation  interchange  procedures  that  require  the  collection,  report¬ 
ing,  and/or  exchange  of  data  needed  to  perform  defense  missions. 

1.2  SCOPE 

The  guidance  is  provided  for  two  components.  First,  it  may  be 
used  by  organizational  elements  of  the  DoD  community.  It  may 
also  be  useful  to  organizations  external  to  DoD  that  exchange  data 
with  the  DoD  community  in  the  course  of  their  business  relation¬ 
ships. 

The  DoD  community  encranpasses  the  Military  Services,  Organiza¬ 
tions  of  the  Joint  Chiefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  referred  to  as  the  DoD  Components.) 

Organizational  entities  external  to  DoD  include  (a)  non-Govem- 
ment  organizations,  both  commercial  and  nonprofit;  (b)  Federal 
agencies  of  the  United  States  Government  other  than  DoD; 
(c)  local  and  state  governments;  (d)  foreign  national  governments; 
and  (e)  international  government  organizations. 

The  draft  convention  published  in  this  document  is  for  trial  use 
and  comment.  DoD  Components  must  submit  to  the  DoD  EDI 
Executive  Agent  (EA)  their  data  requirements  that  are  not  covered 
in  the  conventions  as  soon  as  possible,  as  indicated  in  Chapter  2.0, 
Section  2.1. 

1.3  RESPONSIBLE  ENTITY 

The  Defense  Logistics  Agency  (DLA)  is  DoD’s  Executive  Agent 
for  implementing  and  maintaining  Defense-wide  programs  for 
(a)  EDI  in  accordance  with  DepSecDef  memorandum  of  May  24, 
1988,  Subject:  Electronic  Data  Interchange  of  Business-Related 
Transactions:  and  (b)  Protection  of  Logistics  Unclassified/Sensi¬ 
tive  Systems  (PLUS)  in  accordance  with  Assistant  Secretary  of 
Defense  (Production  and  Logistics)  [ASD(P&L)]  memorandum  of 
November  21,  1989,  Subject;  Production  and  Logistics  Task 
Group  for  Data  Protection.  Publication  of  these  conventions  is 
based  upon  this  authority.  See  Cluqiter  2.0  Maintenance,  Section  2.1 
for  office  point  of  contact 


1.4  HOW  TO  USE  THE  IMPLEMENTATION 
CONVENTION 

The  main  topics  and  structures  of  this  document  conform  to  the 
EDI  Implementation  Reference  Manual  Guidelines  document  that 
was  developed  by  a  task  group  of  the  subcommittee  on  education 
and  implementation  of  the  ASC  X12.  The  purpose  of  having 
agreed-upon  topics  and  structure  is  to  facilitate  reference  by  the 
many  industry  and  DoD  personnel  who  are  involved  in  implement¬ 
ing  the  uniform  standards  for  electronic  interchange  of  business 
transactions. 

1.4.1  Conventions,  Standards,  and  Guidelines 

The  terms  conventions,  standards,  and  guidelines  are  used 
throughout  the  document  and  are  defined  as  follows; 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  ASC  X12  standards.  Conventions  define  what  is 
included  in  a  specific  implementation  of  an  ASC  X12  standard. 

•  Standards  are  the  technical  documentation  approved  by 
ASC  X12;  specifically,  transaction  sets,  segments,  data  ele¬ 
ments,  code  sets,  and  interchange  control  structure.  Standards 
provide  the  structure  for  each  ASC  X12  document. 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI.  Guidelines 
are  intended  to  provide  assistance  and  should  not  be  your  sole 
source  of  information. 

1 .4.1 .1  Who  Develops  the  Conventions? 

Conventions  result  from  a  joint  effort  between  business,  technical, 
and  EDI  ASC  X12  standards  experts.  The  business  data  require¬ 
ment  is  defined,  a  transaction  set  is  selected,  and  the  data  require¬ 
ment  is  then  identified  with  data  elements  in  the  transaction  set. 
A  convention  is  usually  developed  before  any  computer  EDI  sys¬ 
tems  development  work  and  serves  as  a  design  document  when  the 
development  process  begins. 

1 .4.1 .2  Why  Use  a  Convention? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  X12  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  this  task  is  contained  in  the  convention 
document.  Users  who  follow  the  convention  will  create  a  transac¬ 
tion  set  that  all  DoD  users  understand. 

1 .4.1 .3  Who  Needs  a  Convention? 

System  analysts  and  application  programmers  who  plan  to  create 
or  read  ASC  X12  transactions  use  a  convention  to  aid  in  interface 
software  design.  The  convention  will  help  the  programmer  and 
analyst  identify  where  their  application  data  requirement  should  be 
carried  in  an  ASC  X12  transaction  set. 
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1 .4.4.4  Can  I  Develop  a  Convention? 

Conventions  ^eady  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization's  EDI  coordinator  at  the  start  of  an  EDI  project. 
If  you  find  no  conventions  for  the  business  practice  you  are  about 
to  implement,  your  EDI  coordinator  should  contact  the  DoD  Ex¬ 
ecutive  Agent  for  EDI.  See  Chapter  2.0,  Maintenance,  Section  2.1 
for  the  point  of  contact. 

1.4.2  Documentation  Of  Conventions 

Conventions  are  adopted  from,  and  are  intended  to  be  in  confor¬ 
mance  with,  ANSI  ASC  X12  standards  or  ASC  XI2  Draft  Stand¬ 
ards  for  Trial  Use  (DSTU). 

1. 4.2.1  Transaction  Set 

Figure  1.4-1  provides  an  example  of  a  transaction  set  table.  The 
transaction  set  defines  information  of  business  or  strategic  sig¬ 
nificance  and  consists  of  a  transaction  set  header  segment,  one  or 
more  data  segments  in  a  specified  order,  and  a  transaction  set 
trailer  segment.  The  actual  ASC  X12  standard  as  it  appears  in  the 
official  ASC  X12  standards  manual  is  presented  on  the  right  side 
of  the  page.  This  standard  also  includes  both  syntax  notes  and 
comments.  The  specific  DoD  usage  designator  is  presented  on  the 
left  side  of  the  page. 

The  designation  “N/U”  spears  in  the  left  column  if  DoD  does  not 
use  the  specific  segment.  A  page  number  will  appear  if  the  segment 
is  used. 

1. 4.2.2  Transaction  Set  Segment 

Figure  1.4-2  is  an  example  of  a  transaction  set  segment. 

DoD  usage  is  specified  on  the  left  side  of  the  page.  For  identifier 
(ID)  —  type  data  elements,  acceptable  code  values  are  listed  on 
the  right  side  of  the  page  under  the  definitions  of  the  element. 

DoD  notes,  reflecting  how  the  convention  is  to  be  used  appear  on 
the  right  side  of  the  page  at  the  segment  level  or  the  data  element 
level. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  DoD-specific  segment 
directory  section  of  the  convention.  For  ASC  X12  usage,  see  the 
definitions  in  XJ2.6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  are  defined  by  ASC  X12. 

•  Optional 

Optional  data  elements  are  used  at  the  discretion  of  the  sending 
party  or  are  based  upon  mutual  agreement  between  trading 
partners. 
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824  Application  Advice 

Ttiis  Standard  provides  the  format  and  establishes  the  data  contents  of  the 
Application  Advice  Transaction  Set  (824)  within  the  context  of  an  Electronic 
Data  Interchange  (EDI)  environment.  This  transaction  set  provides  the  ability 
to  report  the  results  of  an  application  system's  data  content  edits  of 
transaction  sets  The  results  of  editing  transaction  sets  can  be  reported  at  the 
functional  group  and  transaction  set  level,  in  either  coded  or  free-form  format. 
It  is  designed  to  accomodate  ttie  business  need  of  reporting  the  acceptance, 
rejection  or  acceptance  with  change  of  any  transaction  set.  The  Application 
Advice  should  not  be  used  in  place  of  a  transaction  set  designed  as  a 
specific  response  to  another  transaction  set  (e  g.,  purchase  order 
acknowledgment  sent  in  response  to  a  purchase  order). 
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BGN  •  BEGINNING  SEGMENT  ANSI  ASC  X12  VERSION/RELEASE  003010DOD. 
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•  Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules,  but  are  required  by  DoD  decision. 

•  Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  DoD,  but  the  industry  recommends 
their  use  to  facilitate  EDI.  Most  companies  in  the  ndustry 
are  expected  to  use  this  data  element. 

•  Not  Used 

“Not  Used”  data  elements  are  those  that  the  DoD  does  not 
use. 

•  Conditional 

Conditional  data  elements  depend  on  the  presence  of  other  data 
elements  in  the  transaction  set. 


.6 


BASEUNE  AS  OF:  JANUARY  29,1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


2.0  MAINTENANCE 

This  chapter  describes  the  procedures  for  maintaining  the  DoD 
conventions.  It  also  presents  a  section  on  version/release  timing. 

2.1  MAINTAINING  CONVENTIONS 

Ti.e  DLA,  as  DoD’s  Executive  Agent  for  EDI  and  PLUS,  has 
established  a  joint  program  office  to  oversee  implementation  of 
EDI.  Some  of  the  functions  of  this  program  office  are  to  maintain 
configuration  control  of  related  standards  and  common  support 
packages  (e.g.,  versions  of  ASC  X12  standards  and  PLUS  algo¬ 
rithms  employed),  participate  in  the  standards-setting  process,  and 
ensure  compliance  with  approved  EDI  standards. 

To  accomplish  these  functions,  the  joint  program  office  has  estab¬ 
lished  a  conventions  and  standards  development  and  maintenance 
process  whose  objectives  are:  (1)  to  obtain  ASC  XI 2  data  require¬ 
ments  from  the  DoD  Components  and  present  the  requirements  to 
the  ASC  X12  for  consideration  as  ANSI  standards,  and  (2)  to 
develop  and  maintain  conventions  for  use  by  DoD  Components 
and  their  potential  trading  partners. 

To  take  advantage  of,  and  not  duplicate,  existing  data  stan¬ 
dardization  processes,  the  EA  has  established  focal  points 
within  the  ASD  Offices,  the  Military  Services,  and  the  Defense 
Agencies  from  which  EDI  information  is  obtained  and  dissemi¬ 
nated. 

The  EA’s  primary  source  of  information  about  DoD’s  data  require¬ 
ments  is  the  EDI  User. 

Changes  to  this  publication  and  recommended  changes  to  ANSI 
ASC  X12  should  be  forwarded  through  your  organizational  point 
of  contact  for  data  standardization  to: 

EDI  Su-.'  */ds  Coordinator 
ATTN;  DLA-ZC 
.Tameron  Station 
Alexandria,  VA  22304-6100 

See  Chapter  4  for  reproducible  ASC  X12  Work  Request  forms. 

2.2  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version”  of  a  standard  is  critical  to 
the  successful  interchange  of  information.  Each  participant  must 
be  ^ble  to  send  and  receive  the  same  version  to  ensure  the  accuracy 
of  the  information  exchanged. 

The  version  is  transmitted  as  a  12-character  code  in  the  Functional 
Group  Header  aegment  (GS)  in  Data  Element  #480,  Ver- 
sion/ReleaseAndusiry  ID.  This  12-character  code  is  used  by 
ASC  XI 2  as  follows; 
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Position 

Omieai 

1-3 

Version  number 

4-5 

Release  level  of  version 

6 

Subrelease 

7-12 

DoD/lndustry  or  Trade  Association  ID 

ASC  X12  assigns  the  codes  in  positions  1  through  6. 

A  major  version  (1-3)  will  change  only  after  an  official  public 
review  cycle,  leading  to  republication  of  a  new  American  National 
Standard. 

Release  level  of  each  new  major  version  (4-6)  will  begin  at  “000” 
and  incremented  by  1  for  each  new  ASC  X12  approved  publication 
cycle,  usually  once  a  year.  The  fifth  character  designates  the 
release  and  the  sixth  character  designates  the  subrelease. 

DoD/Industry/Trade  Association  ID  (7-12)  is  used  to  identify 
conventions.  For  this  sufHx,  DoD  will  use  “DoD_”  with  the  10th 
character  identifying  successive  publications.  The  11th  and  12th 
characters  may  be  used  by  the  Military  Departments  or  Defense 
Agencies. 

DoD  conventions  for  using  ASC  X12  standards  are  published 
annually.  Conventions  developed  for  each  release  will  be  main¬ 
tained  for  4  years.  Military  Services  and  DoD  Agencies  will 
determine  which  release  to  use  on  the  basis  of  business  need  but 
will  not  use  any  release  more  than  4  years  old  without  t^proval 
of  the  DoD  EA. 
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3.0  DoD  CONVENTIONS  FOR  USING 
ASC  X12  TRANSACTION  SETS 

This  chapter  defines  the  DoD  transaction  set  conventions.  It 
includes  the  instructions  for  implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  applicable  codes. 

3.1  INTRODUCTION 

The  power  of  the  ASC  X12  standard  is  in  its  building  block 
concept,  which  standardizes  the  essential  elements  of  business 
transactions.  It  is  analogous  to  a  “standard  bill  of  materials  and 
the  construction  specifications,”  which  gives  the  architect 
flexibility  in  what  can  be  designed  with  standardized  materials  and 
procedures.  The  EDI  system  designer,  like  the  architect,  uses  the 
ASC  X12  standards  to  build  business  transactions  that  are  often 
different  because  of  their  function  and  yet  utilize  the  ASC  X12 
standards.  The  “bill  of  materials  and  the  construction  specification" 
of  ASC  X12  are  the  standards  found  in  the  published  technical 
documentation. 

ASC  X12.3  -  The  Data  Element  Dictionary  specifies  the  data 
elements  used  in  the  construction  of  the  segments  that  comprise 
the  transaction  sets  developed  by  ASC  XI 2. 

ASC  X12.5  -  The  Interchange  Control  Structure  provides  the 
interchange  control  segment  (also  called  an  envelope)  of  a  header 
and  trailer  for  the  electronic  interchange  through  a  data  transmis¬ 
sion;  it  also  provide  a  structure  to  acknowledge  the  receipt  and 
processing  of  the  envelope. 

ASC  X12.6  -  The  Application  Control  Structure  defines  the  basic 
control  structures,  syntax  rules,  and  semantics  of  EDI. 

ASC  X  12.22  -  The  Data  Segment  Directory  provides  the  defini¬ 
tions  and  specifications  of  the  segments  used  in  the  construction 
of  transaction  sets  developed  by  ASC  XI 2. 

The  DoD  convention  in  Section  3.4  conform  to  the  above  standards 
and  each  transaction  set  is  a  complete  document  to  the  extent 
possible.  For  further  clarification  of  acronyms,  abbreviations,  and 
codes,  refer  to  ASC  X12  published  technics  documentation.  Con¬ 
tact  the  DoD  EDI  Executive  Agent  for  copies  or  the  Data  Inter¬ 
change  Standards  Association,  Inc.,  Suite  3SS,  1800  Diagonal 
Road,  Alexandria,  VA  22314. 

3.2  CONTROL  SEGMENTS 

In  addition  to  the  communication  control  structure,  the  EDI  structure 
provides  the  standards  user  with  multiple  levels  of  control  to  ensure 
data  integrity.  It  does  so  by  using  header  and  trailer  control  segments 
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designed  to  identify  uniquely  the  start  and  end  of  the  interchange 
functional  groups  and  transaction  sets.  The  relationship  of  these 
control  segments  is  shown  in  Figure  3.2-1.  Control  Segment 
specifications  are  defined  in  Section  3.2.2. 

3.2.1  Description  of  Use 

The  interchange  header  and  trailer  segments  surround  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions: 

•  Define  the  data  element  separators  and  data  segment  ter¬ 
minators 

•  Identify  the  sender  and  receiver 

•  Provide  control  information 

•  Allow  for  authorization  and  security  ..iformation. 

The  Interchange  Acknolwedgment  Segment  is  used  to  acknowledge 
one  interchange  header  and  trailer  envelope  where  the  envelope 
surrounds  one  or  more  functional  groups.  (No  acknowledgment  is 
made  for  the  interchange  acknowledgment.) 

The  interchange  control  number  value  in  the  acknowledgment 
(TAl  segment)  is  the  same  as  that  for  the  ISA  segment  that  is 
being  acknowledged.  The  control  number  serves  as  a  link  between 
the  interchange  header  and  trailer  and  the  acknowledgment  of  that 
header  and  trailer. 

The  interchange  acknowledgment  does  not  report  any  status  on  the 
functional  groups  contained  in  the  interchange  and  is  separate 
from  the  communication  system’s  error  procedures. 

The  preparer  of  the  interchange  header  and  trailer  indicates  the 
level  of  acknowledgment  in  Data  Element  113,  Acknowledgment 
Requested.  If  an  acknowledgment  is  requested,  then  the  recipient 
must  return  an  acknowledgment.  If  not  requested,  none  should  be 
given. 

The  interchange  acknowledgment  control  segments  are  placed  after 
the  interchange  header  and  before  the  first  function^  group  or 
before  the  interchange  trailer  if  there  are  no  functional  groups. 

Control  segments  are  standard  for  all  implementation  conventions 
produced  for  the  Department  of  Defense.  Some  codes  associated 
with  individual  data  elements  within  the  control  segments  are 
unique  to  the  individual  transaction  set.  Others,  identify  the  ANSI 
version  and  release  in  which  the  convention  is  written. 
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Communications  Tronsport  Protocol 

Interchonge  Control  Header _ 

Functional  Group  Header 


.  Functional  Group  Trailer _ 
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Figure  3.2-1.  Hierarchical  Structure 
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Segment:  ISA  Interchange  Control  Header 

Purpose:  To  start  and  identify  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

DES.  ELEMENT  NAME _ ATTRMUTES 

ISA01  101  Authorization  information  Qualifier  M  iD  2/2 

Code  to  identify  the  type  of  information  in  the  Authorization  Information. 

00  No  Authorization  Information  Present  (No  Meaningful  Information  in  102) 

ISA02  102  Authorization  Information  M  AN  10/10 

Information  used  for  additional  identification  or  authorization  of  the  sender  or  the 
data  in  the  interchange.  The  type  of  information  is  set  by  the  Authorization 
Information  Qualifier. 

Implementation  Note: 

If  no  authorization  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA03  103  Security  Information  Qualifier  M  iD  2/2 

Code  to  identify  the  type  of  information  in  the  Security  Information. 

01  Password 

ISA04  104  Security  Information  M  AN  10/10 

This  is  used  for  identifying  the  security  information  about  the  sender  or  the  data 
in  the  interchange.  The  type  of  information  is  set  by  the  Security  Information 
Qualifier. 

Implementation  Note: 

An  agreed  upon  password.  If  no  security  irformation  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA05  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

An  agreed  upon  designation  ofDoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

ISA06  106  Interchange  Sender  ID  M  ID  15/15 

Identification  code  published  by  the  sender  for  other  parties  to  use  as  the 
receiver  ID  to  route  data  to  them.  The  sender  always  codes  this  number  in  the 
sender  ID  element. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 


Mandatory 


ISA07  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
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Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Code  Value  Implementation  Note: 

An  agreed  upon  designation  ofDoD  Activity  Address  Code  (DoDAAC }  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

ISA08  107  Interchange  Receiver  ID  M  ID  15/15 

Identification  code  published  by  the  receiver  of  the  data.  VJhen  sending,  it  is 
used  by  the  sender  as  their  sending  ID,  thus  other  parties  sending  to  them  will 
use  this  as  a  receiving  ID  to  route  data  to  them. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 

ISA09  108  Interchange  Date  M  DT  6/6 

Date  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  YYMMDD 

ISA10  109  Interchange  Time  M  TM  4/4 

Time  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  HHMM 

ISA11  110  Interchange  Control  Standards  Identifier  M  ID  1/1 

Coda  to  identify  the  agency  responsible  for  the  control  standard  used  by  the 
message  that  is  enclosed  by  the  interchange  header  and  trailer. 

U  U.S.  EDI  Community  of  ASC  XI 2.  TDCC,  and  UCS 

ISA12  111  Interchange  Control  Version  Number  M  ID  5/5 

This  version  number  covers  the  interchange  control  segments  and  the  functional 
group  control  segments. 

00301  Draft  Standard  for  Trial  Use  Approved  for  Publication  by  ASC  X12  Procedures 
Review  Board  Through  October  1990 
Code  Value  Implementation  Note: 

Version  ID  as  defined  or  agreed  upon  by  the  trading  partners. 

ISA13  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

ISA14  113  Acknowledgment  Requested  M  ID  1/1 

Code  sent  by  the  sender  to  request  an  interchange  acknowledgment. 

0  No  Acknowledgment  Requested 
1  Interchange  Acknowledgment  Requested 


Mandatory 


ISA15 


114  Test  Indicator  M  ID  l/l 

Code  to  indicate  whether  data  enclosed  by  this  interchange  envelope  is  test  or 
production. 

P  Production  Data 
T  Test  Data 
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Code  Value  Implementation  Note: 

Assigned  by  translation  software. 


Mandatory 


ISA16  115  Subetoment  Separator  M  AN  1/1 

This  is  a  field  reserved  for  future  expansion  in  separating  data  element 
subgroups.  (In  the  interest  of  a  migration  to  international  standards,  this  should 
be  different  from  the  data  element  separator). 

Implementation  Note: 

Use  character 
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Segment:  GS  Functional  Group  Header 

Purpose:  To  indicate  the  beginning  of  a  functional  group  and  to  provide  control 
information 

Syntax:  The  data  interchange  control  number  (GS06)  in  this  header  must  be 
identical  to  the  same  data  element  in  the  associated  Functional  Group 
Trailer  (GE02). 

Comment:  A  functional  group  of  related  transaction  sets,  within  the  scope  of  X12 

standards,  consists  of  a  collection  of  similar  transaction  sets  enclosed  by 
a  functional  group  header  and  a  functional  group  trailer. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

KEF.  DATA 

OES.  ELEMEKT  NAME _ ATmiWn-ES 

GS01  479  Functional  Identifier  Code  M  ID  2/2 

Coda  identifying  a  group  of  application  related  Transaction  Sets. 

Implementation  Note: 

Choose  the  code  value  appropriate  to  the  information  content  of  the  functional  group.  See  XI 2  Dictionary  for 
source  code  list. 


TX  Text  Message  (864) 

GS02  142  Application  Sender’s  Code  M  AN  2/15 

Code  identifying  party  sending  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  Recommend  for  increased  security  that  non-DoD  code  differ 
from  that  used  in  ISA06. 

GS03  124  Application  Receiver’s  Code  M  AN  2/15 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

DoD  activities  use  Department  cf  Defense  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  Recommend  for  increased  security  that  non-DoD  code  differ 
from  that  used  in  ISA08. 

GS04  29  Group  Date  M  DT  6/6 

Date  sender  generated  a  functional  group  of  transaction  sets. 

Implementation  Note: 

Assigned  by  translation  software. 

GS05  30  Group  Time  M  TM  4/4 

Time  (HHMM)  when  the  sender  generated  a  functional  group  of  transaction  sets 
(local  time  at  sender's  location). 

Implementation  Note: 

Assigned  by  translation  software. 

GS06  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 
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Mandatory 


Mandatory 


Implementation  Note: 

Assigned  by  translation  software. 

GS07  455  Responsible  Agency  Code  M  ID  1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard. 

X  Accredited  Standards  Committee  XI 2 

Code  Value  Implementation  Note: 

Indicates  that  an  ANSI  X 12  standard  is  being  transmitted. 

GS08  480  Version/Release/Industry  ID  Code  M  ID  1/12 

Code  indicating  the  version,  release,  subrelease  and  industry  identifier  of  the  EDI 
standard  being  used.  Positions  1  -3,  version  number;  positions  4-6,  release  and 
subrelease  level  of  version;  positions  7-12,  industry  or  trade  association  identifier 
(optionally  assigned  by  user). 

003010  Draft  Standards  Approved  By  ASC  X1 2  Through  June  1 990. 

Code  Value  Implementation  Note: 

Code  value  agreed  to  by  trading  partners.  See  X12  Dictionary  for  source  code  list. 
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Segment:  GE  Functional  Group  Trailer 

Purpose:  To  indicate  the  end  of  a  functional  group  and  to  provide  control 
information 


Syntax:  The  data  interchange  control  number  (GE02)  in  this  trailer  must  be 

identical  to  the  same  data  element  in  the  associated  Functional  Group 
Header  (GS06). 

Comment:  The  use  of  identical  data  interchange  control  numbers  in  the  associated 
functional  group  header  and  trailer  is  designed  to  maximize  functional 
group  integrity.  The  control  number  is  the  same  as  that  used  in  the 
corresponding  header. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REP.  DATA 

OES.  ELEMEWT  NAME _ ATTWIDUTES 

GE01  97  Number  of  Transaction  Sets  Included  M  NO  1/6 

Total  number  of  transaction  sets  included  in  the  functional  group  or  interchange 
(transmission)  group  terminated  by  the  trailer  containing  this  data  element. 

Implementation  Note: 

Assigned  by  translation  software. 

GE02  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  control  number  of  the  preceding 
GS06  control  number. 
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Segment:  lEA  Interchange  Control  Trailer 

Purpose:  To  define  the  end  of  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DAT* 

DES. _ EtEMEWT  NAME _ ATTRIRUTES 

IEA01  116  Number  of  Included  Functional  Groups  M  NO  1/5 

A  count  of  the  number  of  functional  groups  included  in  a  transmission. 

Implementation  Note: 

Assigned  by  translation  software. 

IEA02  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  pa  ties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  number  must  match  the  number  that  occurs  in  ISA13. 
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KXAMPT.F.  .  TFTCT  TR ANSAfTTON  SKT  (fUiA\ 


ASC  X12  EDI  FORMAT 
ST*864*(XX)1  N/L 

BMG*00*ANNUAL  RENEWAL  NA. 
DTM*097*930106N/L 
N1*FR**10*AF1234  N/L 
PER*IC*TERRI  SALES«EM*WP001222345  NA- 

Mrr*WPOfi0900Z*FAILURE  TO  PROVTOE 
COMPLETE,  ANNUAL  UPDATED 
INFORMATION  TO  THE  POP  NA- 

Nl*TO**33*A24567NA- 
REF*ME*XYZ930105Z  NA- 


nFFTTsnTTON 

THIS  IS  AN  864  TEXT  MESSAGE 
TRANSACTION  SET  WITH  A  CONTROL 
NUMBER  OF  0001. 

THIS  IS  AN  ORIGINAL  TRANSMISSION  THE 
SUBJECT OFWmCH IS  "ANNUAL RENEWAL". 

THE  TEXT  MESSAGE  WAS  CREATED  ON 
JANUARY  6. 1993. 

THE  MESSAGE  ID  FROM  A  DOD  ACTIVITY 
WHOSE  DODAAC  IS  AF1234. 

THE  INFORMATION  POINT  OF  CONTACT  IS 
TERRI  SALES  AND  HER  ELECTRONIC  MAIL 
ADDRESS  IS  WP001222345. 

WPAFB  ASSIGNED  THE  MESSAGE 
REFERENCE  NUMBER  "WF06090QZ"  TO  THIS 
TEXT  MESSAGE  WHICH  HAS  AN  EXTENDED 
SUBJECT  OP  TAILURE  TO  PROVIDE 
COMPLETE.  ANNUAL  UPDATING 
INFORMATION  TO  THE  POP. 

THE  MESS  AGE  IS  BEING  SENT  TO  A 
COMPANY  WHOSE  CAGE  CODE  IS  A24567. 

THIS  MESSAGE  REFERENCES  THE  XYZ 
COMPANY'S  INCOMING  MESSAGE  NUMBER 
XYZ930105Z. 


BASELINE  A8  OF:  JANUARY  29, 1993 


3.0.17 


DEPARTMENT  OP  DEFENSE 

DRAFT  MPLEMENTATION  CONVENTION _ 

864  •  TEXT  MESSAGE 

ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 


MSG*YOU  AGREED  AS  A  CONDITION  OF  TEXT  OF  MESSAGE  AS  SHOWN. 

REGISTTIATTON,  TO  PROVIDE  A  COMPLETE 
ANNUAL  DATA  UPDATE  IN  ACCORDANCE 
WITH  POP  INSTRUCTION  AOl,  DATED 
DECEMBER  25, 1991.  YOUR  UPDATE  DID  NOT 
INCLUDE  THE  NUMBER  OF  EMPLOYEES  OR 
THE  ANNUAL  REVENUE  OF  YOUR  COMPANY 
FOR  THE  LAST  YEAR-  N/L 

MSG*IF  THIS  INFORMATION  IS  NOT  RECEIVED 
BY  FEBRUARY  6, 1993,  THE  XYZ  WIDGET 
COMPANY  WILL  BE  DROPPED  FROM  THE  ROLL 
OF  COMPANIES  AUTHORIZED  TO  SUBMIT 
QUOTATIONS  IN  THE  POP.  N/L 

SE*11*0001  N/L  THERE  ARE  11  SEGMENTS  IN  THIS 

TRANSACnON  SET  AND  THE  CONTROL 
NUMBER  IS  0001. 


NOTE:  ALL  NUMBERS  ARE  NOTIONAL  AND  USED  FOR  ILLUSTRATION  PURPOSES  ONLY. 


BALANCE  OF  THE  TEXT  MESSAGE 
(REMEMBER,  THAT  DE  933  CAN  CARRY  A 
MAXIMUM  OF  264  CHARACTERS). 


3.0.18 


BASEUNE  AS  OF;  JANUARY  29. 1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


864  •  TEXT  MESSAGE 

ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 

3.4  DoD  CONVENTION 

BASEUNE  AS  OF:  JANUARY  29, 1993 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


3.0.20 


BASEUNE  AS  OF:  JANUARY  29, 1993 


864 -TEXT MESSAGE 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  00301  ODOD_ 


1 


DC07  •  JANUARY  29  1993 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 


18  060 
N/U  070 
20  080 


REF  Reference  Numbers 

PER  Administrative  Communications  Contact 

MSG  Message  Text _ 


864 -TEXT MESSAGE 


O  12 

O  3 

M  100000 


PAGE*  POS.» 

21  010 


Table  3 

SEG.ID  NAME _ 

SE  Transaction  Set  Trailer 


REa  DES.  MAX  USE _ LOOPRB»EAT 

M  1 


DC07>  JANUARY  29  1993 


2 
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3 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


864 ’TEXT MESSAGE 

DTM  •  DATEnriME  REFERENCE  ANSI  ASC  X12  VERSION/RELEASE  00301  ODOD_ 


Optional 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Syntax: 


DTM  Date/Time  Reference 

Header 


Optional 

10 

To  specify  pertinent  dates  and  times 

At  least  one  of  DTM02  or  DTM03  must  be  present. 


Mandatory 


Conditional 

Not  Used 
No’  ’Jsed 


Data  Element  Summary 


REF. 

OES. 

DATA 

ELEMEWr 

NAME 

ATTRIRirrCS 

DTM01 

374 

Date/Time  Qualifier 

Code  specifying  type  of  date  or  time,  or  both  date  and  time. 

M 

ID 

3/3 

097 

Transaction  Creation 

DTM02 

373 

Date 

Date  (YYMMDD). 

C 

DT 

6/6 

DTM03 

337 

Time 

C 

TM 

4/4 

DTM04 

623 

Time  Code 

O 

ID 

2/2 

5 
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864  •  TEXT  MESSAGE 

ANSI  ASC  X12  VERSION/RELEASE  00301  ODOD_  N1  •  NAME 


DC07  •  JANUARY  29  1993 


6 


DEPARTMENT  OF  DEFENSE 
DRAFT  tMPLEMENTATION  CONVENTION 


864 'TEXT MESSAGE 

N2  •  ADDIT'ONAL  NAME  INFORMATION 


Optional 


z  INFORMATION  ANSI  ASC  X12  VERSION/RELEASE  003010DO'J_ 


Segment:  N2  Additional  Name  Information 
Level:  Header 
Loop:  N1 
Usage:  Optional 
Max  Use:  2 

Purpose:  To  specify  additional  names  or  those  longer  than  35  characters  in  length 


Data  Element  Summa 


Mandatory 

Optional 


REF. 

OES. 

DATA 

ELEMEKT 

NAME 

N201 

93 

Name 

Free-form  name. 

N202 

93 

Name 

Free-form  name. 

_ «Ttm»UTES 

M  AN  1/35 

O  AN  1/35 
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ANSI  ASC  X12  VERSION/RELEASE  003010DOD 


864 'TEXT  MESSAGE 
N3  •  ADDRESS  INFORMATION 


Optional 


Segment:  N3  Address  Information 
Level:  Header 
Loop:  N1 
Usage:  Optional 
Max  Use:  2 

Purpose:  To  specify  the  location  of  the  named  party 


Mandatory 


Optional 


Data  Element  Summary 


NEF. 

OES. 

DATA 

ELEMEKT 

NAME 

ATTRIBUTES 

N301 

166 

Address  Information 

Address  information 

M 

AN  1/35 

N302 

166 

Address  Information 

Address  information 

O 

AN  1/35 

0C07  •  JANUARY  29  1993 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


864 'TEXT  MESSAGE 

N4  •  GEOGRAPHIC  LOCATION  ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 


Optional 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Symax: 


Comments: 


N4  Geographic  Location 

Header 

N1 

Optional 

1 

To  specify  the  geographic  place  of  the  named  party 

1.  At  least  one  of  N401  or  N405  must  be  present. 

2.  If  N401  is  present,  then  N402  is  required. 

3.  If  either  N405  or  N406  is  present,  then  the  other  is  required. 

1.  A  combination  of  either  N401  through  N404  (or  N405  and  N406)  may 
be  adequate  to  specify  a  location. 

2.  N402  is  required  only  if  city  name  (N401 )  is  in  the  USA  or  Canada. 


Conditional 


Conditional 


Optional 


_  _ Data  Element  Summary _ 

RCF.  DATA 

0«».  nmUT  MAMB _ ATTIiaUTES 

N401  19  CHyName  C  AN  2/19 

Free-form  text  for  city  name. 

N402  156  State  or  Province  Code  C  ID  2/2 

Code  (Standard  State/Province)  defined  by  appropriate  governmental  agencies. 

N403  116  Postal  Code  O  ID  4/9 

Code  defining  international  postal  zone  code  excluding  punctuation  and  blanks 
(zip  code  for  United  States). 

Implementation  Note: 

Use  only  when  the  address  of  the  selling  party  has  no  ZIP  code  but  may  have  another  type  of  postal  code 
(e.g.,  in  a  froeign  country) 


Optional 


N404  26  Country  Code  O  ID  2/2 

Code  identifying  the  country. 

Implementation  Note: 

The  DoD  uses  DoD  5000.12-M  for  country  codes.  A  translation  table  might  be  required. 


Not  Used 
Not  Used 


N405 

N406 


309  Location  Qualifier 

310  Location  Identifier 


O  ID  1/2 

C  AN  1/25 
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DEPARTMENT  OF  DEFENSE 
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ANSI  ASC  X12  VERSION/RELEASE  003010DOD 


864 ’TEXT MESSAGE 
REF  •  REFERENCE  NUMBERS 


Optional 


Mandatory 


Conditional 


Segment:  REF  Reference  Numbers 
Level:  Header 
Loop:  N1 
Usage:  Optional 
Max  Use:  12 

Purpose:  To  specify  identifying  numbers. 

Syntax:  Either  REF02  or  REF03  is  required. 

Implementation  Note: 

When  a  Unique  Tracking  Number  has  been  provided  in  a  previous  transaction,  one  iteration  of 
REF01I02  is  required  on  all  transactions  sent  by  the  government  in  order  to  carry  the  Unique 
Tracking  Number  ( UTN)  for  the  transaction  set. 

_ Data  Element  Summary _ 


RCF. 

oes. 


DATA 

ELEMEKT 


ATTWIEIffES 


REF01  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

Implementation  Notes: 

1.  Use  code  TN  to  qualify  the  identifying  number  of  the  824.  838(R),  838(C),  or  841,  transaction  sets. 

2.  Use  code  DX  to  qualify  the  identifying  number  of  the  840  transaction  set. 

3.  Use  code  IV  to  qualify  the  identifying  number  of  the  810  transaction  set. 

4.  Use  code  ME  to  qualify  the  identifying  number  of  the  864  transaction  set. 

5.  Use  code  PR  to  qualify  the  identifying  number  of  the  843  transaction  set. 

6.  Use  code  SI  to  qualify  the  identifying  number  of  the  856  transaction  set. 

7.  Use  code  PO  or  CT  to  qualify  the  identifying  number  of  the  836,  850, 855,  860,  and  865  transaction  set. 

8.  When  sending  a  message  referencing  an  RFQ,  both  code  DX  (representing  the  RFQ  ruimber)  and  code  IX 
(representing  the  RFQ  line  item  ruunber)  must  be  transmitted. 

9.  When  sending  a  message  referencing  a  contract  or  purchase  order,  the  contract  line  item  number  (code 
C7)  must  be  transmitted  along  with  either  the  contract  number  (code  CT)  or  the  purchase  order  number 
(codePO). 

10.  Use  code  65  for  the  Unique  tracking  ruunber  (UTN). 

65  Total  Order  Cycle  Number 
C7  Contract  Line  Item  Number 
CT  Contract  Number 
DX  Department/Agency  Number 
IV  Seller's  Invoice  Number 
IX  Item  Number 
ME  Message  Address  or  ID 
PO  Purchase  Order  Number 
PR  Price  Quote  Number 

SI  Shipper's  Identifying  Number  for  Shipment  (SID) 

TN  Transaction  Reference  Number 


REF02  127  Reference  Number 


C  AN  1/30 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


864 'TEXT  MESSAGE 

REF « REFERENCE  NUMBERS _ ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Implementation  Notes: 

1.  When  the  REFOl  qualifier  is  code  OX,  transmit  the  RFQ  number  in  BQT02  of  the  840  transaction  set  and 
the  RFQ  line  item  number  in  POlOl . 

2.  When  the  REFOl  qualifier  is  code  IV,  transmit  the  invoice  number  in  BIG02  of  the  810  transaction  set. 

3.  When  the  REFOl  qualifier  is  code  ME,  transmit  the  number  in  MflOl  of  the  864  transaction  set. 

4.  When  the  REFOl  qualifier  is  code  PR,  transmit  the  price  quote  number  in  REF02  of  the  843  transaction 
set. 

5.  When  the  REFOl  qualifier  is  code  SI,  transmit  the  number  in  BSN02  of  the  856  transaction  set. 

6.  When  the  REFOl  qualifier  is  code  TN,  transmit  the  number  in  BGN02  of  the  824  transaction  set;  the 
number  in  BTP02  of  either  the  838(R)  or  838(C)  transaction  sets;or  the  number  in  REF02  of  the  841 
transaction  set. 

7.  When  the  REFOl  qualifier  is  code  CT  or  code  PO,  transnut  the  number  in  BCO04  of  the  836  transaction 
set;  the  number  in  BEG03  or  BEG06/BEG04  and  the  number  in  POlOl  of  the  850  transaction  set;  the 
number  in  BAK03  or  BAK07IBAK05  and  the  number  in  POlOl  of  the  of  the  855  transaction  set;  the  number 
in  BCH03  or  BCH08/BCH04  and  the  number  in  POCOl  of  the  860  transaction  set;  or  the  number  in  BCA03 
or  BCA08IBCA04  and  the  number  in  POCOl  of  the  865  transaction  set. 


Conditional 


REF03  352  Description  C  AN  1/80 

A  free-form  description  to  clarify  the  related  data  elements  and  their  content. 


11 
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DRAFT  IMPLEMENTATION  CONVENTION 


864 'TEXT  MESSAGE 

MIT  •  MESSAGE  IDENTIFICATION 


Mandatory 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 

Comments: 


Mandatory 


REF.  DATA 

OES. _ ELEMEMT 


MIT01  127 


Optional 


MIT02  352 


Not  Uaad 
Not  Used 


MIT03  931 
MIT04  932 


_ ANSI  ASC  X12  VERSION/RELEASE  003010DOD 

MIT  Message  Identification 
Detail 

MIT  Repeat:  200 

Mandatory 

1 

To  identify  the  beginning  of  a  specific  message  and  to  allow  the 
identification  of  a  subject  for  the  message. 

1.  MIT01  contains  the  message  number. 

2.  MIT02  contains  the  message  subject. 

3.  MIT03  default  is  80  characters. 

4.  MIT04  default  is  66  lines. 

_ Data  Element  Summary _ 

name _ ATTRaUTES _ 

Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Description  O  AN  1/80 

A  free-form  description  to  clarify  the  related  data  elements  and  their  content. 

Page  Width  O  NO  1/3 

Page  Length  Lines  O  NO  i/3 
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N2  •  ADDITIONAL  NAME  INFORMATION  ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 


Optional 


Segment:  N2  Additional  Name  Infoimation 
Level:  Detail 
Loop:  N1 
Usage:  Optional 
Max  Use:  2 

Purpose:  To  specify  additional  names  or  those  longer  than  35  characters  in  length 


Mandatory 


Optional 


_ Data  Element  Summary _ 

REP.  PATA 

PES.  ELEMENT  NAME _ ATTRIBtfTES 


N201 

93 

Name 

Free-form  name. 

M 

AN 

1/35 

N202 

93 

Name 

Free-form  name. 

O 

AN 

1/35 

15 
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Optional 


Segment:  N3  Address  Information 
Level:  Detail 
Loop:  N1 
Usage:  Optional 
Max  Use;  2 

Purpose:  To  specify  the  location  of  the  named  party 


864 -TEXT  MESSAGE 
N3  •  ADDRESS  INFORMATION 


Mandatory 


Optional 


Data  Element  Summary 


REF. 

DiS. 

DATA 

ELEMEMT 

NAME 

ATTRUlinES 

N301 

166 

Address  Information 

Address  information 

M 

AN 

1/35 

N302 

166 

Address  Information 

Address  information 

O 

AN 

1/35 
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N4  •  GEOGRAPHIC  LOCATION  ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 


Optional 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Syntax: 


Comments: 


N4  Geographic  Location 

Detail 

N1 

Optional 

1 

To  specify  the  geographic  place  of  the  named  party 

1.  At  least  one  of  N401  or  N405  must  be  present. 

2.  If  N401  is  present,  then  N402  is  required. 

3.  If  either  N405  or  N406  is  present,  then  the  other  is  required. 

1.  A  combination  of  eHher  N401  through  N404  (or  N405  and  N408)  may 
be  adequate  to  specify  a  location. 

2.  N402  is  required  only  if  city  name  (N401)  is  in  the  USA  or  Canada. 


Conditional 


_ Data  Element  Summary _ 

MF.  DATA 

OP.  ILPaEMT  NAME _ ATTWUTP 


N401  19  CMyName  C  AN  2/19 

Free-form  text  for  city  name. 


Conditional 


Optional 


N402  156  State  or  Province  Code  C  ID  2/2 

Code  (Standard  State/Province)  defined  by  appropriate  governmental  agencies. 

N403  116  Postal  Code  O  ID  4/9 

Code  defining  international  postal  zone  code  excluding  punctuation  and  blanks 
(zip  code  for  United  States). 

Implementation  Note: 

Use  only  when  the  address  of  the  selling  party  has  no  ZIP  code  but  may  have  another  type  cf  postal  code 
(e.g,  in  a  foreign  country) 


Optional 


Not  Used 
Not  Used 


N404  26  Coun^  Code  O  ID  2/2 

Code  identifying  the  country. 

Implementation  Note: 

The  DoD  uses  DoD  5000.1 2-M  for  country  codes.  A  translation  table  might  be  required. 

N405  309  Location  Qualifier  O  ID  1/2 

N406  310  Location  Identifier  C  AN  1/25 
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864 'TEXT MESSAGE 

REF  •  REFERENCE  NUMBERS 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


Conditional 


ANSI  ASC  X12  VERSION/RELEASE  00301 ODOD_ 

2.  When  the  REFOI  qualifier  is  code  IV,  transmit  the  invoice  number  in  BIG02  of  the  810  transaction  set. 

3.  When  the  REFOI  qualifier  is  code  ME,  transmit  the  number  in  MITOl  of  the  864  transaction  set. 

4.  When  the  REFOI  qualifier  is  code  PR,  transmit  the  price  quote  number  in  REF02  of  the  843  transaction 
set. 

5.  When  the  REFOI  qualifier  is  code  SI,  transmit  the  number  in  BSN02  of  the  856  transaction  set. 

6.  When  the  REFOI  qualifier  is  code  TN,  transmit  the  number  in  BGN02  of  the  824  transaction  set;  the 
number  in  BTP02  of  either  the  838(R )  or  838( C )  transaction  sets;or  the  number  in  REF02  of  the  841 
transaction  set. 

7.  When  the  REFOI  qualifier  is  code  CT  or  code  PO,  transmit  the  number  in  BCO04  o/  the  836  transaction 
set;  the  number  in  BEG03  or  BEG06/BEG04  and  the  number  in  POlOl  of  the  850  transaction  set;  the 
number  in  BAK03  or  BAK07/BAK05  and  the  number  in  POlOl  of  the  of  the  855  transaction  set;  the  number 
in  BCH03  or  BCH08/BCH04  and  the  number  in  POCOl  of  the  860  transaction  set;  or  the  number  in  BCA03 
or  BCA08/BCA04  and  the  number  in  POCOl  of  the  865  transaction  set. 

REF03  352  Description  C  AN  1/80 

A  free-form  description  to  clarify  the  related  data  elements  and  their  content. 
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864 -TEXT MESSAGE 
MSG  •  MESSAGE  TEXT 


Mandatory 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 

Comment: 


MSG  Message  Text 

Detail 

MIT 

Mandatory 

100000 

To  provide  a  free  form  format  that  would  allow  the  transmission  of  text 
information. 

MSG02  is  not  related  to  the  specific  characteristics  of  a  printer,  but 
identifies  top  of  page,  advance  a  line,  etc. 


Mandatory 


Optional 


REP. 

DATA 

OES. 

ELEMENT 

MSG01 

933 

MSG02 

934 

Data  Element  Summary 


NAME 


ATTWIBin’ES 


Free-Form  Message  Text  M  AN  1/264 

Free-form  message  text. 

Printer  Carriage  Control  Code  O  ID  2/2 

A  field  to  be  used  for  the  control  of  the  line  feed  of  the  receiving  printer. 


DC07' JANUARY  29  1993 
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4.0  ASC  X  12  FORMS 


In  this  chapter,  applicable  ASC  X12  forms  are  presented. 


BASEUNE  AS  OF:  JANUARY  29, 1993 


4.0.1 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


DEPARTMENT  OF  DEFENSE 
DRAFT  NyiPLEMENTATION  CONVENTION 


SPORIIATWil  MANUAL 


VIII  ~  FORMS,  FORMS,  FORMS 


ASC  X12  Work  Rsquosi  Form 

ASC  X12  N«w  Proiset  Proposal  Form 

ASC  X12  Now  Transaction  Sat  Oavtiopmant  Fom 

Fonn  for  Naw  or  RavMad  Appandb  A  Coda  Sourca  Rafaranca 

Documant  Proparation  for  imatprotatlorM.  Quidalinas  and  Coraiol  Standards 

Sampia  Transfflital  Form 

ASC  X12  Balot  Commant  Rasponsa  Lattar  Fonnat 
ASC  X12  Standards  Order  Form 


FAUiass 


VIII- 1 


BASEUNE  AS  OF:  JANUARY  2S,  ISOS 


44.S 


Pm.  5/10/90  DM  NUMBER _ 

DATE  SUBMITTED  (SMrMartat  Only) 

- -  ASCX12 

WORK  REQUEST  FORM 

ALL  REQUESTS  MUST  BE  TYPED  or  prMod  logibiy  m  biacfc  Ink.  Compiato  tMCh  sUm. 

1.  TOUSETHISFOI1MFORSUPKRrMaOATAMAMTENANCEFORANEWDRAn’STANOAK)ORX12INTEnPRETATION.IMtf 
r*quit«mwttenONEtom.  Um  MAdimwNi  ••  naoMiMy.  mHlm«5t>»»i>9wmia.Hwi5»>w»d«imttmwi/cod»>/cod>tOMfOt«. 
ThulWwyWowtlPMitilngMgfmiimnddainWiwwti/Bodw/ooOxouww.  Thtn  M  any  oOMia  (•.g..  X124.  X12J). 

Z  TOUSETHISPOm4TOREQUESTACHANQCrOANeaSTMQSTANOAR).yMaMpMMWlMkRiquMlftnnioli«aNchangMlar 
ana  vanaaeMen  aat  ana  tagmam.  ana  contel  alniewa,  ar  aM  data  aiamant  At  aaedana  muai  ba  aampMad.  Anaatanantt  may  ba  uaad 
tor  aandnuaiian  and  thauM  ba  Aufflband. 

3.  TOUSETHISFOBMTOW6QueSTAFWOPOSa)Newxi2tWOJ6CT.aambtoto8ieilBn  A.  PrawMa  a  purpaaa/aeapa  and  daaeriba  «iy 
naw  toaturaa  Invatoad  in  Sacdan  A  PniMt  a  daaeripden  ol  Pm  buiiwaaa  naad  and  iuadtealton  tor  dia  naa>  pm|aci  In  Saedan  C/Pmt  5  Tha 
Wtorti  Rasuaat  «nl  ba  torwaidad  to  an  apprepriato  Xia  aubeammdtoa  tor  analyaia  and  piaparadan  at  a  piaiact  pwpaaal. 

CIreteOfM:  (i)N«w  Standard  Supporting  OatiMainignanca(iMatiactMngnig) 

Existing  Standard  MaMananca  Raquast  (saa  Sacdon  D) 

0)  Raquast  tar  Now  X12  Proiaet 


Acwnyma/ibbfai^irtBna  cannat  ba  addad  to  tia  atondaada.  toduaby  ipadSc  torma  muai  ba  Qaady  laglUnad.  rnrtttt  ryuianrtlM  n  nnrta 
aoumaratoraneaatoralaiMmaaypubtiahadaedalalicaad.  toeamglato  tonwa  ar  dwaa  «dd>  Inadaauata  augpart  ter  tia  eDanga  taquaawd 
aril  ba  ratumad  to  «w  aubmMar. 

A.  SUBMITTbH  INf-UHMAtlON  — — 

SubmRlon  Nama  _ 

Company 

Addross  _ 

Addrass/ZIP 

Phono  _ 


Indicata  tha  XI 2  subcommlitaa  or  taafc  group  whoao  position  is  raprasantod  hora. 

I  daelara  that  tMarapraaorda  tha  oMdal  position  of  X12  WORK  GROUP: _ 

aatabliahad  at  tha  moating  datad _ 

B.  PROPOSED  WORK:  List  tha  spacMc  changas  to  tha  standards  baing  rsquaatsd.  GIva  tha  namas  and 
assodatsd  idsntlllara  of  tha  standards,  sagmsnts.  data  aiamonu  and  codas  affsctad. 


4A.4 


BA8ELME  AS  OF:  JANUARY  29, 1995 


OEFAimHMTOF  OCFBIW 
CNUrr  MPLEHENTATION  OOlMBfTION 


Pag«T\Mo 

C.  REASON  FOR  CHANGE: 

Parti:  Uat  tha  varsion/raiaaaa  of  tha  ttandard  you  art  using  or  using  as  a  rafaranca.  Nama  iha  tranaaetion  aat 
that  la  baIng/wW  ba  uaad  that  dictatas  tha  raquastad  changad.  List  affactad  sagmanu  and  data  aiamanta,  or 
othar  standards.  Provida  only  rafaranea  numbars/IOs. 

Rafaranea  Seurea  Varslon  2/Ralaaaa _ 

Tranaaetion  Sat  Uaad 

Sagmant  Affactad  _ 

Data  Elamant  Affactad _ 

Othar  Standard _ 

Partll:  Explain  why  you  naad  tha  propoaadchanga.  Provida  a  compiata  seanarlo  that  tata  what  tha  businaas 
function,  opsratioa  or  problam  is  that  wlbasatisfiad  by  a  changa  to  tha  standard.  ThaXiZJTachnieal 
Aasassmant  Subcommittaa  raquiras  anough  Mormation  in  this  Part  II  to  ba  abla  to  propoaa  an  aitamaia  solution  V 

nocosaary. 


D.  Humifications:  lfyoucirctad(2)onPaqat.eomptatathiasactlorv  Tosnaurathatairatnaicailonaofyour 
propoaad  changa  ara  racordad  and  that  your  laquast  la  complata.  drcla  balow  al  sacdona  of  tha  standarda 
affactad  by  tha  propoaad  changa. 


TRANSACTION  SET  Nmiw  AxpoM/Seops  Tasw  Now/Commsm 


SEGMENT 


OATAELfMENT 

COOE 


kSn/MM 
MS  was 


RntH  Mow  Sofvwnso  Now 


Ooooriaaon  Jm 


OoWwCoao  NooWoCoao 


OTHER  (a.g..X12.S.X12.8): 

ERRORS  NOTED  IN  THE  STANDARD  (QNa  paga  na  and  othar  kfartflcMior^: 


■AMUNE  At  OF:  JANUARY  ».  ISSa 


4.0.S 


4/1/90 


DVAimiBIT  OF  OmSMf 

DRAFT  MFLEMENTATION  CONVOmON 


PP  No. _ 

(Socrttarlat  Only) 


ASC  X12 

NEW  PROJECT  PROPOSAL  FORM 

PROCEDURE:  Only  X12  subcommlRees  may  uso  this  form  to  register  new  dovtiopment  activities  as  X12  project 
proposals  (PPs).  Cocnplata  all  pagos.  PPs  approvad  by  tha  X12  Procaduras  Review  Board  wll  be  registarad  and 
assigned  a  PP  number  by  OfSA,  and  a  Transmittal  Form  will  be  issued. 

Data  and  complete  tha  form  below.  Typa  or  print  legibly  in  black  ink  and  number  all  attachment  pages 
consecutively.  Submit  to  DISA  prior  to  an  ASC  Xt2  meeting,  or  to  X12J  Technical  Assessment  Subcommittee 
during  the  subcommittae's  agenda  period  at  an  ASC  X12  meeting. 


Date  SubmMad: 

Date  Approved  by  Subcommittee: 

Subcommittee  Name: 

Task  Group  Name/No'.: 

Joint  Development  Subcommittee  (H  any): 

Cireie  one:  (a)  Transaction  Set  (b)  Quideiine  (e)  Other 

Protect  Working  TMIa: 


Official  Delcgate(8)  for  This  Protect  To  Bo  Named  on  Transmittal  Form; 
Name _ Nama _ 

Company _ Con^iany _ 


Address _ ^Address _ 

Address/ZIP _ _Addresa/ZlP 

Telephone _ _Teiephone  _ 


4.0.6 


BASEUNE  A8  OF:  JANUARY  29. 1993 


A.  PURPOSE  AND  SCOPE  FOR  THE  PROPOSED  WORK:  ProMtd*  a  purpoM/acop*  for  th« 

prapo3«dwoffc.  SMXiSOMignRulMandQukMinMforraquiranMntt. 


B.  BACKGROUND;  Pfow>d«  dattte  thii  vi<i  bt  htipM  In  riwtawHnq  tht  propoMi  Who  af  th>  aKp<cfd  uMn? 
HowwBth««andinltMUMcr?  Whai  bushtau  (uneiion(t)  do«  I  Mfv«7.  EttwpfopoMdttandardovaifapstha 
functienaliiy  of  an  ttdHIno  Aindaid  or  ont  In  dMilopnwni.  proMa  juMlIallaa  Nttiaprapoaallinoifbranawr 
atandaitf  or  guidaiina,daaeHbatlw  protact  In  datal.  (Uaa  attadananta  i  naraaaary.) 


t.  OTHER  STANDARDS  lWvOi.vfa);  H  appUcafala.  Want#y  any  othar  bualnaaa  WorwaBon  Randaida  tlSTara 
aimlar/ialatad  to  tha  propoaal,  and  nama  attndarda  dawaiopara  (0.0..  ANSI  Accradtad  Siandarda  Commaiaaa) 
whoaa  actMiiaa  may  ba  iTMOIvad  or  aBaeiad. 


0.  EXPECTED  CONTENT/QENERAL  DESCRIPTION:  (dmONAL)  Subrnttar  imy  ttach  a  pt^bnirwry  draft  of 
tbapropoaadatandaidoroiharaupportinQdoojmaraaiion.  DIactm  now  aoBmaiOa.  data  aiamania,  control 
«nicturaa.andchangaatoXiUorXiZ6tMararaquiradorariidpttod.  (UaaaBactwnanti.) 


BASBUNE  M  OP:  JANUARY  2a.  1003 


OEPARTMBfT  OP  DTOOE 

DRAFT  MPLiyCNTATION  C0NVBIT10N 


FORM  FOR  NEW  OR  REVISED 
APPENDIX  A  CODE  SOURCE  REFERENCE 

INSTRUCTIONS:  Complete  this  form  whenever  a  naw  data  eiement  or  data  at«fnent  coda  is  to  ba 

added  which  references  a  code  list  published  by  an  extemai  (non-Xl2)  organization.  Use  one  form  for  each  new 
reference.  This  form  may  be  used  to  revise  current  references;  fai  out  the  appropriate  areas  below. 


CIRCLE  ONE,  COMPLETE  AS  APPROPRIATE: 

(1)  NEW  REFERENCE 

(2)  REVISED  REFERENCE.  Current  reference  number/name 


REFERENCE  TITLE:  If  there  is  only  one  source  for  codes  for  the  dau  element  the  title  should  be  the  same  as  the 
data  element  name.  If  there  are  rruitlple  codes  referencing  external  code  sources  for  the  same  data  etemert,  tide 
should  approximate  the  code  definition. 

REFERENCE  TITLE: 


DATA  ELEMENTS  USED  IN:  Give  the  data  element  reference  number  and  name  which  directs  the  user  to  this 
Apperxtlx  A  code  source  refdrance.  Give  the  code  10  (If  assigned)  if  this  Is  for  a  specific  code  of  the  data  slemanL 

USED  IN;  DE  No. _ .  Code  ID _ 


SOURCE:  Provide  the  name  of  the  publication  which  contains  the  codes  referenced. 

PUBUSHED  IN: 

AVAILABLE  FROM:  Give  the  publisher,  or  other  contacL  from  whom  the  user  can  obtain  the  document 

Name/Attn  of  _ 

Company _ 

Address _ 

Address  _ 

Addrese/ZIP  _ 

ABSTRACT:  Briefly  describe  the  publication,  Its  purpose,  and  Indicate  what  codes  It  contaiiZ 
ABSTRACT: 


4J).S 


BASEUNE  AS  OF:  JANUARY  2S.  ISSS 


OEPARTMBITOF  0EFB4SE 
DRAFT  IMPLEMENTATION  CONVBITION 


DOCUMENT  PREPARATION  FOR 
INTERPRETATIONS,  GUIDELINES  AND  CONTROL  STANDARDS 


Rpr.  4/1/» 


Th«M  instructions  art  provldsd  to  assist  dsvalopars  of  intarpratations.  guidalinss  and  control  structura  which  art 
not  transaction  sats  (for  transaction  sau  usa  tha  Naw  Transaction  Sat  Davaiopmant  Fonn). 

GENERAL:  OISA  proMldas  tHa  paga  and  front  mattar  for  publications  and  copyadlts  tha  documant  according  to 
OISA  housa  styla. 

REVIStCMS:  Ifthadocumantisaravisionofapravioualypublishadintsrpratation,  guidalinaorstaiidaid,  providaa 
summary  of  tha  changas  to  tha  originai  that  ara  containad  in  tha  documart 

I  INTERPRETATIONS 

A  formal  intarpratation  of  an  Xt  2^  Standard  Is  considorod  part  of  tha  body  of  standards  whan  it  Is  approwad  for 
publication.  Tha  Intarpratation  draft  shotidstata  tha  isauaprasantad  by  tha  raquastor.stata  tha  proposad 
intarpratation.  and  show  as  attachmaras  any  Work  RaquMts  that  may  banacaasary  to  aflact  tha  intarpratailon 
within  tha  subiact  standard.  Tha  draft  Intarpratation  is  procasaadUka  any  otharsubcommittsa  documant 

U  QUIOEUNES 

For  publieationpurposas.guldalinas  ara  traatadUra  a  journal  artida.  Basic  ragukamanu  ara  gNan  balow. 

ABSTRACT:  TMs  is  a  pradsa  summary  of  tha  Purpoaa/Scopa  (saa  balow),  «id  may  ba  Uantical  to  fe  I  that  la  brtsf 
(two  paragraphs):  otharwIaaaummartM  tha  purpoaa/scopa.  K  shoiM  contain  anou^  Momnation  abou  tha 
documara  to  anabla  a  raadar  datanmina  what  tha  guidaiina  ia  kaandad  to  accornpiiah  wIMn  an  EDI  arwironinant 

PURPOSE  AND  SCOPE:  This  statamant  must  Indtcata  purpoaa  of  tha  guldallna.  a.a.  tha  businaas  function  or 
oparationaddrasaad.  Scopa  and  any  spacilc  Imkationa  of  scopa  shodd  ba  dsflnad. 

BOOYOPTEXT:  This  may  ba a  numbar  of  subsactions logicaly  organizad.  Prowidasaetionatarforawoid. 
iraroduction,  dafinition  of  tanns  and  concapts,  rahRaneas  and  ralatad  standards,  maihodology,  spadHcationa. 
raquiramants,  discussion,  and  conclusions,  as  approprina  to  tha  subjaa 

ART  AND  GRAPHICS:  Graphics  or  artwork  nacassary  to  Hustrata  tha  documant  ara  ancouragad.  Provida 
camara-raady  copy  if  thaaa  ara  not  akaady  praparad  and  dailvarad  on  a  WP  diskatta  to  DISA. 

FOREWORD,  FOOTNOTES,  APPENDICES:  Thasa  may  ba  usad  for  purpoaaa  of  clarity,  Buatration,  or  ganarai 
inforniation.notas*paitofthaguidaNnai'  A  statarnara  indicating  tha  rnatarW  to  tor  Mormation  purpoaaa  only  and 
not  part  of  tha  guUaiina  shal  appaar  at  tha  baglrming  of  a  toraword  or  appandbt 

III  CONTROL  STRUCTURES  AND  OTHER  STANDARDS 

For  publlcatton  purpoaaa.  thaaa  documanu  ara  traatad  Ilka  guidallnas  (saa  Saction  II  abowa).  Tha  raqukamanu  ara 
tha  sama,  with  tha  addRion  of  tha  tolowing: 

NEW  SEGMENTS  AND  DATA  ELEMENTS:  Thasa  may  ba  dafinad  wkhin  tha  taxt;  howavar,  slnoa  thay  raprasara 
changas  to  X12.22  and  X12.3.  thay  shotSd  ba  spadfiad  on  a  Work  Raquast  Fonn  atlachad  to  tha  draft. 

RELATED  X12^  STANDARDS  AND  OTHER  REFERENCES:  Thasa  shal  ba  UantMad  In  a  saction  wfthin  tha  taxL 


BASEUNE  A8  OF:  JANUARY  28. 1903 


4.0.9 


OCPAimiBfT  OF  O0B4SE 

DRAFT  MFLEMENTATION  C0NVB4T10N 


HSATwo 

FORMAT:  TNi  Draft  Standard  lor  TfW  Um  contains  ih«  (ormat  and  MtAbilMiM  tht  dati  cortantt  o(  th« 

_ Transaction  Sat  (  1  (or  uaa  wthin  iha  eontaxt  of  an  Bactronie  Oau  Intarefianga  (EDI) 

arMlronnwnL  Tha  transaedon  sat  (can  ba  uaad  la..)* 


C.  RURR08I  AMD  SCOPi  Thtt  staMtnsnt  must  Mdlcata  tha  M  ranga  Of  capabHias  Of  Pis  tranaacOon  sat  and 
whothasandara/racaivaraara.  Syialnihabusinass  function  or  oparatlon  that  Is  addrauad.  FolowASCXiS 
Oasign  RUaa  and  Guldslinas  and  uaa  diis  (onnac 

FORMAT:  *rNs  standard  prowldss  tha  forniat  and  astablishas  tha  data  eontanis  of  tha _ Transaction 

SatMraMnihacoraoBdofanBacifonicOouintarehango(EOI)anw(ronnionL  TMs  transaction  sat  (can  baussdta..)* 


D.  TIUWlACTiawiiTtAkjE(8)  For  each  taMa  pfO¥lda  tha  iOaowlno  Worntioa  FORMAT: 

TAILEX 


POSITION  SEGMENT  REQ.  MAX. 

tfO. Xfi _ title _ PES..,ttSEL 

010  ST  TranMCtion  S«t  HMdor  M  1 

020  BE  Baginning  Sogaant  For  M  I 

•te. 


LOOP  REPEAT  NOTE 

COOMT _ BOj. 

Nota  1 
Conant  l 


Natal:  TNsisanata  NOTES  ara  pan  of  thsstandaid(numbarad). 

CommaraA:  TNsisaoommara.  COMMENTS  ara  not  pan  of  thasrandardgapsrsd). 


1  iPPENOlkfitAAlAlii  SwnpiasM  Mad'toiaS'SaniaTof'SapraposaS'nnaSonlndlo'SivBn^  to 
M  MH  onv  wnpv  9  vnviQHinr*  NO  vocoQnaDW  pfopor  nomoi  nvy  oo  uno  vi  viy  wnfoo. 

PIQUflEl:  (Optional)  Uaa  a  aamplapapardoeumont  using  mock  dMa.  If  uaad.  doia  must  ba  aceurotaly  mapped 
toFlgursE  OrtginalgrapMeomuaiboaBBChod (§•1/2x11*) so tfiay can baooplod. 

PIQURf  2  (or  EXAMPLE):  THaSiallguraandproMdaaBuainaasSeananeioaRplalntottiaraodarwhatagoing 
onlnthaaBcampla  Addthanoia:  TnWsaxam^thaaatartekC) rapraaantaPtadaiaalamarasaparatOf andPa 
N/L  charactara  rapraiant  tha  aagmara  tarmlnaior.*  Prasara  EDI  tranamisslen  data  and  is  moaning  In  hso  columns. 
sidaAiy-sida  ZZor2ZZcodosaradtaoouragod.aineatt)sirusafiJnasslnanaD9lonatoryoKampiaisnl.  FORMAT: 

BUSINESS  SCENARIO:  In  iMs  bansoctlon  sat  tha  sandar  N  XVZ  Ratal  Csrasr  and  Pa  racoNar  Is  Pair  suppHsr, 
Fantasde  Produca  Maradactatng.  ln&...aia 

EDI  TRANSMISSION  BATA _ (TRANSACTION  SET  PURPOSE)  DATA 

ST*SXX*0005  N/L  Bagin  Tranaaetion  Sat  SXX;  Control 

No.  0005 

BB*01*79t00*  N/L  Original  Transaisaion;  Raf.  No. 

79B00 

ate. 


4.0.10 


BASEUNE  AS  OF:  JANUARY  29, 199S 


DEPARTtlBiT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


S/10/B0 

OMNumbsr _ 

(Sscrattritt  Oniy) 

DocumsntNo. _ _ 

(OWsiopsr  OtUins  from  OISA) 


ASC  X12 

NEW  TRANSACTION  SET  DEVELOPMENT  FORM 


INSTRUCTIONS:  Um  this  tom)  to  submit  •  drift  trinsaction  sit  for  riwliw  by  X12J  Tichnicai  AsMssmmt  umi  It  Is 
text  procissid  by  OISA.  Usi  a  new  Transaction  Set  Divilopmim  Form  whmivif  riwlslons  in  propoiid  attd  i 
text  fill  has  not  yit  bun  priparid  by  OISA. 

ATTACHMENTS:  Attach  al  pages;  uM  this  form  as  the  first  FoUomt  these  instmctiona  for  preparing  matarlaia. 

The  submktar  must  obtain  a  document  number  assignmara  from  OISA.  Poatfe  to  this  fonn  (above). 

Atuch  a  Uat  of  RavlalotM  If  the  draft  \was  previously  rsviavrad  t)yXl2JorVthisisa  ravlsad/rsdasignad 
transaction  sat  standard  requiring  X12  balot 

Use  ONE  Work  Request  Perm  to  list  all  supporting  data  maintanence  for  the  transaction  sat  and  attach  I 
tothisform.  Propose  new  or  revised  oodea  for  OE 143  and  OE  479  at  a  minimum.  I  raquirad. 

A  Transmittal  Form  must  accompany  this  documara  whan  k  Is  aubmttad  to  OISA  for  distribution. 

Use  the  moat  recant  Standards  Oavalopmant  Workbook  to  chock  your  documara  for  accuracy. 

A.  SUBMIl  IbR  INFORMATION  “ — — 

Submittar  Name 


Company 

Addraw 


Addraas/ZiP 

Phone' 


Indicate  the  Xi2  subeommlltaa  or  task  group  whose  position  is  represaraad  hare. 
I  daclara  that  this  raprasants  the  official  position  of  X12  WORK  GROUP: 
astablishad  at  the  meeting  dated _ 


B.  ABSTRACT  The  Abstract  is  ragistarad  wkh  the  American  Nationai  Standards  Institute.  It  Is  a  pradsa  summary 
of  the  Purposa/Scopa  (see  Section  C  bdow).  It  may  baktemical  totha  Purpoaa/Scopa  Vthat  ia  brief  (two 
paragraphs),  otharwisa  summarize  the  purpoaa/scopa.  It  should  comaln  aiiough  Information  about  the  standard 
to  anabia  a  potantlai  user  datarmina  what  aquNaiant  paper  transaction  ft  represaras  or  what  the  standard  is 
Intended  to  do.  Folcwthalonnatonpagatwo. 


BASEUNE  AS  OF:  JANUARY  29, 19SS 


4.0.11 


DEPARTMENT  OF  OffBME 
DRAFT  MPLEHENTATION  CONVBfTION 


Rm.  5/10/90 

SAMPLE  TRANSMITTAL  FORM 


inltializid 

KEY  DATE:  Fabnttry  18, 1890 


DELEGATES  NAME 
RESPONSIBLE  SUBCOMMiTTEE/TG# 

TRANSACTION  SET/GUIDEUNE  TITLE 

BALLOT  Document  No. 

Current  Document  No. 

Previous  Document  No. 

Project  Proposal  No. 

Associated  WR/DM  No. 


PROJECT  PROPOSAL 
PP  Review  by  X12J 
PRB  Approves  PP 


John  Doe 

ASC  X120  XX  Subcommlttae/TG4 
X12J0(  ABC/XYZ  TRANSACTION  SET  (8XX) 


ASCX12Q/90-051 
ASCX12Q/90<004 
PP-99Q 
DM  012-190 


(DATE)  2/7/90 
PATE)  2/9/90 


DEVELOPMENT  PHASE:  Project  proposal  apprcNal  throu(^  approval  tar  X12  vote. 


Document  Submittad  tar  DISA  Text  Processing  PATE) 

Subcommittee  Approves  Draft  tar  Review  by  XI 2J,  Tech  Asseasmant  PATE) 

Xl2JTech  AssessmsntRaviaw  (DATE) 

PRB  Approves  Document  tar  XI 2  Vote  PATE) 


ORIGINAL  BALLOT  DATA  piSA): 


Ballot  Qosed  Date  PATE) 

Tally/Comments  Sent  to  Chalr/Delegates  PATE) 

Tally  Stats  (Number  and  Percent) 

_ Ballou  Malsd  (100%) 

_ Ballou  Returned  ( _ ^%) 

_ Approved  ( _ ^%) 

_ Appw/Convnent  ( _ ^%) 

_ Disapproved  ( _ ^%) 

_ Abstained  ( _ %) 


4.9.12 


■AMUNE  AS  OF;  JANUARY  29. 1993 


OEPARTMBIT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


PagtTwe 

COMMENT  RESOLUTION  PHASE:  Sm  Ssctiont  A.  B  and  C.  tf  tha  lubconKnlRaa  at  any  tima  daddaa  to  rabalat 
tha  documanL  PRB  approval  la  raquirad  and  rasponaa  laltars  ara  not  nacaaaary. 

A.  COMMENT  RESPONSE  LETTERS:  An  Opan  Forum  muat  ba  sctiadulad  at  tha  nod  XI 2  maatlng  following  tha 
balot  doting  data.  Att  thoaa  who  commantad  racaiva  a  commani  ratponaa  lattar  from  tha  davaloplng 
aubcommiRaa.  OISA  racoida  thia  procaaa  and  handMa  tha  mating. 


OpanForumOata  (DATE) 

Ratponaa  Laoara  Malad  Out  by  OISA  (DATE) 

RabuRal  Parlod  (30  days)  Ooaaa  (DATE) 


ADJUSTED  BALLOT  DATA  piSA): 

StFOay  Ratponaa  RavtawOoaad  Data  (DATE) 

Taly/Commantt  Sa<«  to  Chalr/Dalagataa  (DATE) 


Taly  Stata  (Numbarand  Paroant) 

_ Balou  Malad  (100%) 

_ BaloURatumad  ( _ *) 

_ Approvad  ( _ ^%) 

_ Appw/Commar<  (  %) 

_ Oiaapprovad  ( _ ^%) 

_ Abatafnad  ( _ %) 


B.  SUBSTANTIVE  REVISION:  If  balot  commanu  raadt  in  aubatantNa  raviaiona  to  tha  documars.  thaaa  ara 
lavtawadbyXiajandproeaaaadbyOISA  Tharav«taddocumantltaubmttadtoXt2votaratora30^raviaw 
parlod.  DISAracordathlaprocata/handMamUIng.  SubcommlBaaa  ahouM  conduct  30-day  raviawa  for  ratponaa 
lattara/ravlaad  documantt  ooncurranify. 


Subcommttaa  Approval  of  RavlaionB  (DATE) 

X12J  Ravlaw  of  Ravialona  (DATE) 

OISA  Mala  Ravlaad  Documant  (DATE) 

Subatandva  Raviaion  30-Oay  Ravlaw  Ckiaaa  (DATE) 


ADJUSTED  BALLOT  DATA  piSA): 

30-Oay  SubatandvaChanga  Ravlaw  Qoaad  Data  (DATE) 

Taly/Commanta  Sant  to  Chair/Dalagatat  PATE) 


Taly  Stau  (Numbar  and  Parcant) 

_ Balou  Malad  (100%) 

_ BaloURatumad  ( _ ^%) 

_ Approvad  ( _ %) 

_ Appw/Commani  ( _ ^%) 

_ Oiaapprovad  ( _ %) 

_ Abaialnad  ( _ ^%) 
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PtgcTIVM 

C.  CONTINUING  OBJECTIONS.  If  th«F9  art  continuing  disapprovals  after  the  30-day  review  period,  th« 
document/disapprovais/responsM/contlnuing  objections  are  maled  to  X12  members  who  originally  cast  a  ballot, 
for  another  30-day  review,  to  give  them  an  opportunity  to  change  their  vote. 

Continuing  Objections  Maled  to  Chair/Delegate  by  DISA 
OISA  Mals  Oucuments 
30-0ay  Review  Qoees 

FINAL  ADJUSTED  TALLY  (DISA):  Whenever  any  disapprovals  are  withdrawn,  a  letter  to  this  effect  must  be 
received  in  writing  by  DISA 

FIntf  Tally  Results  Sent  to  Chair/Delegate  PATE) _ 

30-Day  Review  Stats  (Adjusted  Taffy) 

_ Ballou  Maled  (100%) 

_ Ballou  Ratumad  ( _ ^%) 

_ Approved  (_%) 

_ Appw/Commenl  ( _ ^%) 

_ Disapproved  ( _ %) 

_ Absumed  ( _ %) 


PRB  APPROVAL  PHASE:  After  the  comment  resolution  period,  the  stXicommiDee  votes  to  submit  the  documers 
to  the  PRB  for  approval  to  publish. 

Subcommittee  Votes  to  Release  to  PRB  PATE) _ 

PRB  Approves  Publication  (DATE) _ 


FOR  DRAFT  STANDARDS  FOR  TRIAL  USE: 
VERSION/RELEASE/SUBRELEASE  ID  CODE  ASSIGNED: 


PATE) 

PATE) 

PATE) 
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P«0«Fotir 


TfUNSMITTAL  POMI INSTIIUCTION8: 

GCNEfUL  TNiTrinafTMiiiFonnli  a  TURNAROUND  DOCUMENT  which  rseordtttithiitory/cimntttituf  of  a 
pratad  documant  It  la  uaad  to  tehanga  Irdonnaiton  baaxaan  tha  Sacmariat  and  iha  conwMtaaa  of  X12. 
idormadon  la  cumUaiNa  (add  on).  TNatornilaaaachadtothadocumantwAianawartialMuadfQrdiatrlbudonOiia 
wiandaio>ytofauOniailnqdocutnawttioDlSA.Xi2JTachnleal  »waaamant.  and  tha  PRB).  Dooanant  eonirat 
numban  aia  all  raquirad  on  aaeh  doeumart,  and  fMw  numban  ara  raquirad  adianavar  I  la  riMaad. 

KEYOATE:  Thlalauaadtoldani»ythalataaivaraionofthadocumant(dataaaaoclBtadwthihaeunantiianamatal 
tamupdaia). 

Each  auboonvnMaadatignataa  an  lndMdijai(dalagBta)  from  ttia  group  raaponaUa  for  Oiaprejacl 
Tha  SacraMdat  muai  ba  Mormad  I  tha  dalagato  changaa. 

IMTIATION:  RdmarydaialaraoordadbyOlSAonthainllaRzadlonnallarttiapralacipropoaalliapprQwadbyiha 
Tha  aubcomiwBaa  chair  and  dMagataWracaNa  tha  WjateadTtanarnEial  Form  from  DfSA.  diaraaRaf.ihay 
araraaponatda  for  raoording  Iha  appropftaiaauboommiBaa  approval  dataa.  Tha  chalr/dalagata  wd  racaiva  a  copy 
of  Iha  updated  tranamMalfomiiiRianavari  la  ravfaad  by  DfEA. 

UROATINQ:  Aiaaohapproprtaiaattp,DlSAwaROSTbaahdataioihafonn.AOOOianoB(iappfopnaiablanlcsio 
thafofTgandSENDttoihaaubcemmBaachair/dalagBiaaiaachatatuachanoa.  Tha  dalagMamuat  ROST  tha 
form  w«h  fraah  dan  at  aach  ataUB  changa forwdilch  tha  aubcommataa  la  raaponaUa  and  SEND  I  wMi dia 
approprtan  documan  to  Iha  SacratarML 
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ASC  XI 2  BAUQ^COMMENT 


RESPONSE 


:R  FORMAT 


O0ICIUL  MFOmiATION 

AFTW  AM  III  •AUOT,  THE  AMFONNAU  •UOOOMMrnil  (ON  in  OfHOMATID  TA*C  OAOOF)  NWT  iwpontf  h  »  H 

ifcMinmifM  imwi  TIwOuMMMNniPiDBiduwiiMnMllOFtil)!— »«)wmi»noti»q»wdl»>wjBwd»t>ct«w«iifcwn<w 
■p>w<nJ«tit>ceiiwm.bun>pMilylco«wH>twm«wiwpcndii<a.  DwOFMMMtwaaeamMniiMpanMtiiMMbveDaiAnaid 
«Mi  t»  AyfeeammiM  ChMr. 


Wipann  la  — ch  cownnwiDr.  3MinMuaimbMawandtwMnrMninii. 

OFT10N1:  OBOne  LETTER  (MAmmXlTDq  TO  ALL  OOMMBnom 

YoywwypwpiiiotwHBgBbtMwfalflowimMafB.  EwwyaemiMmiMMMdmMitoiipndueidlnyaurlMNr.  Fanadieamnant 
IWid.wiwtwooiwiwwiDfCXiawmbf  oowpany tiwlawdtMWiiliBBrtiJiBfMW.  LMifMiWEonM»l»«iMiM.  Nyw 
clioo— aiMop<ow.yoMiiiiygroMpt»cwwmnii<MiM>imimllif>dmpowdlBtiiwaEWME  Emy  nMAvMEMppnMdimittb* 


OFTHNI:  MOMOUAL  UrTTBI  TO  EACH  OOMMBfTOR 

YMmarprapMOMMarlwMaheamMniar.  MyaHflhBaMMtapaon.yaunMdnaii«pMia«ai<glnilaHniiMpmMMantwbMM. 
MwVayMMlbiMinmtanraiiftoandawEMiwNkwMloMMM.  E(«*y  mmtw  tw  dtaiMrawE  nuit  to  nipondid  ». 


METRUcnONE 

ETVI:  FlaniBp(Mtwlt«piE*«*T«vimitt)anAECXiaMNrtMaA  »ywADnft(MWliaHtiMd,TaueatMinMfmt«nta 
EinfMiofwyeducitmiiNiiAMlwA  Yw wtr owpoi—.fMwfc it—HMd lor )mycDWBtiw»o»iMiWMt». 

•TIFa:  f B n  Itcnirti hr ■  Awimint  iwnirnl niwAir  TM(nuMfeiriiM«apAMrina»iip*vit#iiaaiwaltMar«pi9»«ltalMv. 
Ifinni  wnilanirifiiirtiBlwrtlinrw  wrfinnninwninr  fa  i>iiuiiMH  iiinnl  mmlrr  ■r‘i|ntiffrrTVntrirnTtT*imTitTr»~*** 
(•4..  ARC  xiaFmiMo-iaaAL  «■  maam  »r  •  ’r  <•■».  aec  xiaFiroMo-iaoE).  am. 

ITVa:  OwowyoMrIt«MlawiiMop<an(i«>Oi>iNlnlBwilpnB>»>). 

tTEF4:  FriwwtwIiarlDawfwmtwomirw. >ilw»uwnt«t|>xiMi>winwi  IWwtewiiit 

a.  FfBwdiaaoniMinaw(M»iBn)i«t>»uXEgna>il<n»arto»oHwlMHwrtincludip>icn>WMWibw. 

b.  PrMtMdoGHmMoanMnumbsrundvtaliMrtMndboi. 

c.  FiMtwAMbyntfMtwAaeumMaanmnumbar. 

4.  AdA'wHwlMNriBfwiniKWil.arly  fwrteliAglwAiEiawdOm— ItwaBdbMbiMt**- 
•.  Indu^  tbtWdbcianfF— Enpb  — twIn>i»PW>«ErMw<l>Fl»t»aA>wa>- 
(.  YoMwyiNiiDi—pawbMNily  (>wiiiroirT>niwiMFcnti)lDrti>  WbwiMionaHib  war. 

flTEF4:  FanwrifMlMmibawSaaMMir,  AnMtonEMmrMEMViBH.wMttaMarlMHrraquMbnEOMMonNtriMbanM 
Mwt*)  y«u  hM  ptibMd.  Whan  aw  !■—»  Una  bwn  EmRnMd.tr  pw|Mi4MigMi»<d  wbecnw4Bwctnir»E  ibciMa  an 
TianawMMiFowndMcAhaitMmaRnEdMiandaOdRrMwaaraanoddoaingdaMpoaMd. 


4.0.16 


BASEUNE  AS  OF:  JANUARY  39, 1993 


OEPARTHBfT  OF  OEFB4SE 
DRAFT  MPLEMENTATION  CONVENTION 


ASC  XI 2-ELECTRONIC  DATA  INTERCHANGE  [EDI] 


Tia  Joneacy 
(999)999-9999 


Accredocd  Standards  Committee 
ooerecmg  Lrxier  the  procedires  of  the 
American  Nacnnat  Standards  institute 


Document  iMo 


Daa  Sfflithey 
(999)999-9999 


ASC  X12C/TG20/90.999 


June  25. 1990 


TO:  X12  Meaben  Who  Coaaeoted  oa  Modificatioot  to 

XUjb  Coatroi  Stnictures 

RE:  Respoaie  to  Coaaeats  oe  Deceaber  Ballot 

DMs  205289, 215289, 317289 


Thaak  you  for  your  coaaeats.  This  ballot  iavoKed  aodiScatioos  to  XIIjk  Of  the  327  ballots  Bailed,  153  baiiou  were 
returaed.  Of  these,  81  approved,  15  approved  with  coaaeat,  20  dtsapproved  with  aad  37 

la  geaeral,  the  vote  respoases  were  ia  favor  of  the  aMdifieatioM.  The  asaioniy  of  the  coaacau  focused  oa  the  iapaet 
oftheteaodificatioasoathepreseataliooofiafbraatiQaatheXl2.22Se|aMDwectaty.  The  proposed  aodifieaiioM 
aad  the  resuhagpceseotatioa  a  the  tc^aat  directory  have  beea  reworked  a  reapoaae  to  these  coaaeats.  Areviscd 

aadifirsrina  tA  a  a.. - -  .>  ,i.-  arrti^  Modificaioos  to  the 

doMw  have  beea  Bade  which  reflect  respoases  to  the  eoauneau  from  tha  haOot.  aad  a  revM  copy  of  Xllai  H 
beiag  distributed  to  all  who  voted  oa  this  issue,  for  30'^  review  of  revisiaM. 

SpeoTic  respoases  to  coauseau  foUow. 


COMMENT:  Autoaobile  Corporalioa 

'Add  the  foOowiaf  aote  to  Paragraph  33:  NOTE:  Commuaicatioa  protocol  characters  should  be  froa  the 

SCL* 

RESPONSE: 

The  cover  letter  sea  out  with  the  votiai  package  eapiaiaed  that  the  iateat  wa  to  obiaa  ctaacMia  oa  the  proposed 
aodifieatioas  to  X12a  XUb  is  a  diflkuk  staadard  to  aaead.  We  request  tha  ballot  respoases  be  coasidered  oa  the 
aeriuoftherecoaaseadedaoaficatioasaadactoathestaadardaawhole.  Yea  caaaca  wa  outside  the  scope  of 
the  requested  aodifieatioas. 
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COMMENT:  Aircraft  Eague  CorporatkM 

*Some  comideratioa  for  Abstract  Syntax  Notation  One  (ASN.l)  should  be  allowed. 

1.  ASN.l  is  capable  of  defining  all  of  the  necessary  inter-relations  needed  by  X12  transactions. 

1  ASN.l  requires  leu  characters  to  define  the  same  information. 

3.  ASN.l  is  the  encoding  scheme  used  by  most  OSI  work.* 

RESPONSE: 

The  recommendation  to  consider  usage  of  ASN.l  reaches  far  beyond  the  scope  of  the  modiScations  requested 

inthisbaUoL  Activities  such  at  this  are  best  submitted  as  separate  work  requests. 

COMMENT:  Some  Software  Inc. 

“Conditionality  of  data  elements  should  be  left  to  the  discretioa  of  guidelines  and  apeementn  There  is 

mud  discussion  at  tim  as  far  at  whether  certain  dau  ekmenu  should  be  mandatosy  or  not;  many  appBcation  systems 
are  incapable  of  providing  certain  ‘mandatory  mui,  as  such,  filler-type  must  be  mterted.* 

RESPONSE: 

The  issue  of  dM  element  conditionality  as  a  whole  it  a  much  broader  subject  than  was  intended  to  be  addressed  within 
the  scope  of  this  baOot.  This  ballot  was  ****«»<t»<i  (g  provide  a  means  for  consisteat  «t<winii»iit«riw  ami  application  of 
already  exiatiag  conditional  structures.  If  the  commentor  believes  that  the  conditional  structure  should  be  removed  from 
the  standard,  the  task  group  recommends  that  this  be  submitted  as  a  separate  work  request 

Etc. 
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AocracMad  Scandardi  Commoac 

JoeSoaebody 

operaeng  i/ider  Ow  prKCdures  of  trw 

Chair  TC19,X12C 

Anwxan  Naconal  Standards  msMuca 

(999)999-9999 

Documenc  No 


ASC  X12C/TC8/90-998A 
Ai^Utt  10, 1990 

Ml  JaacDoe 
AacrieaaBaak 
Oae  Ceatral  Pitta 
Middle  Aaerica,  MO  99999 

RE:  Reapooie  to  BaOoi  Coaaaeatt  oa 
ASC  X12  Model  Guideliae 

Dear  Ml.  Doc: 

Subeoamittee  X12C  hai  eapomned  iti  Talk  Group  19  to  provide  rcapoaaca  to  the  oa  thk  baOoL  The 

■eaben  of  TGl9«iih  to  thttk  an  XUaeaben  retook  the  tiae^  effort  to  vote  oathagnidefiae.  We 
ttped^thaak  each  iadividiial  who  provided  coaaeata,  whether  ia  approval  or  diaapproval  of  the  fuidefiae.  We 
reeopae  aad  appreciate  your  careful  review  of  thii  docaaeaL 

Our  rcapooac  ii  keyed  to  the  auabered  keaa  ia  the  eoaneata  attached  to  your  baOoL 

RESPONSE 

L  We  agree  with  your  coaaea.  la  Sectka  4JL!,  «e  have  replaced  >e  adSee  mlei  with  'nilea are  utilized'. 

2.  The  coaflaioo  betweea  Seetida  4.13  aad  Sccdoa  <k2  ooly  eadttt  becawe  of  the  eauBple  we  choae  ia  the  lira 
lectioa.  Thia  ii  a  hypothetical  eaaple,  of  a  tiaplififd  ao^  Headers  aad  traikra  caa  be  piaced  eo  the  cootea  a 
ALL  levels,  aad  do  act  aecosarily  eorrespoad  to  ASC  X12  headers  aad  traSeit. 

1  We  agree  with  your  coaiaKaL  Sectioadlhasbeeathaafedsothatlhcfatabliihaifat  of-*  wasaddedtokcass 
laad4. 
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5.0  GLOSSARY 

This  chapter  contains  ASC  X12  and  DoD  specific  glossaries. 

5.1  X12  GLOSSARY 

ANSI 

American  National  Standards  Institute 
ANSI  Standard 

A  document  published  by  ANSI  that  has  been  approved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
of  these  standards  must  have  been  developed  by  an  ANSI  commit¬ 
tee  and  must  be  revisited  by  that  committee  within  5  years  for 
update.  See  Draft  Standard  for  Trial  Use  (DSTU). 

Area  Transaction  Set 

Identifies  a  predefined  area  within  a  transaction  set  (header,  detail, 
summary)  containing  segments  and  their  various  attributes. 

ASC  X12 

Accredited  Standards  Committee,  X12  comprises  industry  mem¬ 
bers  who  create  EDI  standards  for  submission  to  ANSI  for  sub¬ 
sequent  approval  and  dissemination:  or  for  submission  to  the 
UN/ECE  for  approval  and  submission  of  UN/EDBFACT  stan-dards. 

Authentication 

A  mechanism  which  allows  the  receiver  of  an  electronic  transmis¬ 
sion  to  verify  the  sender  and  the  integrity  of  the  content  of  the 
transmission  through  the  use  of  an  electronic  “key”  or  algorithm 
which  is  shared  by  the  trading  partners.  This  is  sometimes  referred 
to  as  an  electronic  signature. 

Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Conditional  (C) 

A  data  element  requirement  designator  which  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value  or 
presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  computer  processable. 

Control  Segment 

A  Control  Segment  has  the  same  structure  as  a  Data  Segment  but 
is  used  for  transferring  control  information  for  grouping  data 
segments.  Control  Segments  ate  Loop  Control  Segments  (LS/LE), 
Transaction  Set  Control  Segments  (ST/SE),  and  Functional  Group 
Control  Segments  (GS/GE),  defined  in  X12.6,  and  Interchange 
Control  Segments  (ISA/IE/«^A1)  defined  in  X12.5. 
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Data  Element 

The  basic  units  of  information  in  the  EDI  standards  containing  a 
set  of  values  that  represent  a  singular  fact.  They  may  be  single¬ 
character  codes,  literal  descriptions,  or  numeric  values. 

Data  Element  Length 

This  is  the  range,  minimum  to  maximum,  of  the  number  of  char¬ 
acter  positions  available  to  represent  the  value  of  a  data  element. 
A  data  element  may  be  of  variable  length  with  range  from  mini¬ 
mum  to  maximum,  or  it  may  be  of  fixed  length  in  which  the 
minimum  is  equal  to  the  maximum. 

Data  Element  Reference  Number 

Reference  number  assigned  to  each  data  element  as  a  unique 
identifier. 

Data  Element  Requirement  Designator 

A  code  defining  the  need  for  a  data  element  value  to  appear  in  the 
segment  if  the  segment  is  transmitted.  The  X12  codes  are  man¬ 
datory  (M),  optional  (O),  or  conditional  (C).  DoD  may  "require" 
a  segment  which  is  optional  by  X12  standards. 

Data  Element  Separator 

A  unique  character  preceding  each  data  element  that  is  used  to 
delimit  data  elements  within  a  segment.  Dod  uses  as  the 
delimiter. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types:  numeric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

The  delimiters  consist  of  two  levels  of  separators  and  a  terminator. 
The  delimiters  are  an  integral  part  of  the  transferred  data  stream. 
Delimiters  are  specified  in  the  interchange  header  and  may  not  be 
used  in  a  data  element  value  elsewhere  in  the  interchange.  From 
highest  to  lowest  level,  the  separators  and  terminator  are  segment 
terminator  and  data  element  separator. 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organization 
funded  by  ASC  X12  members  which  serves  as  the  Secretariat  for 
X12. 

DSTU 

Draft  Standard  for  Trial  Use.  Represents  a  document  approved  for 
publication  by  the  full  X12  committee  following  membership  con¬ 
sensus  and  subsequent  resolution  of  negative  votes.  (Final  Report 
of  XI2  Publications  Task  Group).  The  Draft  EDI  Standard  for 
Trial  Use  document  represents  an  ASC  X12  approved  standard  for 
use  prior  to  approval  by  ANSI.  See  ANSI  Standard. 
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EDI 

Electronic  Data  Interchange.  The  computer  application  to  com¬ 
puter  application  exchange  of  business  information  in  a  standard 
format. 

Electronic  Envelope 

Electronic  information  which  binds  together  a  set  of  transmitted 
documents  being  sent  from  one  sender  to  one  receiver. 

Element  Delimiter 

A  single-character  which  follows  the  segment  identifier  and 
separates  each  data  element  in  a  segment  except  the  last. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functional 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  Segments 

GS/GE  segments  identify  a  specific  functional  group  of  documents 
such  as  purchase  orders. 

Industry  Conventions 

Defmes  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  how  to  implement  X12  stand¬ 
ards. 

Interchange  Control  Segments 

ISA/IEA  segments  identify  a  unique  interchange  being  sent  from 
one  sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Structure 

The  interchange  header  and  trailer  segments  envelop  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions;  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  information  for  the  inter¬ 
change,  and  (4)  allows  for  authorizadon  and  security  information. 
(X12.5) 

Loop 

A  group  of  semantically  related  segments;  these  segments  may  be 
either  Ixiunded  or  unbounded  (X12.6).  The  N1  loop  is  an  example 
of  a  loop,  which  includes  segments  N1  to  PER  for  name  and 
address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element  is  required. 
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Mapping 

The  process  of  identifying  the  standard  data  element’s  relationship 
to  application  data  elements. 

Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used  at 
the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
Optional  (O) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element/segment  is  at  the  option 
of  the  sending  party  which  can  be  based  on  the  mutual  agreement 
of  the  interchange  parties. 

Qualifier 

A  data  element  which  identifies  or  defines  a  related  element,  set 
of  elements,  or  a  segment.  The  qualifier  contains  a  code  taken 
from  a  list  of  approved  codes. 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set.  See  Max  Use. 

Securi^ 

System  screening  which  denies  access  to  unauthorized  users  and 
protects  data  from  unauthorized  uses 

Segment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifier,  one  or 
more  data  elements  each  preceded  by  an  element  separator,  and 
ends  with  a  segment  terminator. 

Segment  Directory 

Provides  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifier  for  a  segment  composed  of  a  combination  of 
two  or  three  upper-case  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment.  The  segment 
identifier  is  not  a  data  element.  The  segment  identifier  in 
EDEFACT  is  a  component  data  element  —  part  of  a  composite 
data  element  consisting  of  a  segment  identifier  and  an  explicit 
looping  designator. 
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Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment,  e.g.,  N/L. 

Syntax 

The  grammar  or  rules  which  define  the  structure  of  the  EDI 
standards  (i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules  are 
published  in  ANSI  X12.6. 

Transaction  Set 

The  transaction  set  unambiguously  defines,  in  the  standard  syntax, 
information  of  business  or  strategic  significance  and  consists  of  a 
transaction  set  header  segment,  one  or  more  data  segments  in  a 
specified  order,  and  a  transaction  set  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  fnst  data  element  of  the  transaction  set  header 
segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard  format  and 
translating  them  to  the  standard. 

Version/Reiease 

Identifies  the  publication  of  the  standard  being  used  for  the  genera¬ 
tion  or  the  interpretation  of  data  in  the  X 12  standard  format.  May 
be  found  in  the  Functional  Group  Header  Segment  (GS)  and  in  the 
Interchange  Control  Header  Segment  (ISA).  See  Control  Segment. 

Vies  Committee 

Voluntary  Interindustry  Communications  Standards  for  Electronic 
Data  Interchange 

X12 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  electronic  data  interchange  (EDI). 

X12^ 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic  inter¬ 
change  through  a  data  transmission,  and  it  provides  a  structure  to 
acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.6 

Application  Control  Structure.  This  standard  describes  the  control 
segments  used  to  envelop  loops  of  data  segments,  to  envelop 
transaction  sets,  and  to  envelop  groups  of  related  transaction  sets. 
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5.2  DoD  GLOSSARY 

AIS 

Automated  Information  Systems 
ASD(P&L) 

Assistant  Secretary  of  Defense  (Production  and  Logistics) 

DES 

Data  Encryption  Standard 
DISA 

Defense  Information  Systems  Agency 
DLA 

Defense  Logistics  Agency 
ISA 

Interchange  Control  Header  Identifier 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  Identifier 
PLUS 

Protection  of  Logistics  Unclassified/Sensitive  Systems 
UN/EDIFACT 

EDIFACT;  Electronic  Data  Interchange  for  Administration,  Com¬ 
merce,  and  Transpon 


5.0.6 
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